-
Notifications
You must be signed in to change notification settings - Fork 14
Support omitzero tags in optionalfields linter #115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Karthik-K-N The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@JoelSpeed I spent some time understanding the linter and tried adding support for conisdering omitzero JSON tag. Please let me know what other scenarios needs to be covered. Is it required to add a configuration to suggest/fix? like omitemtpy tag /cc @sbueringer |
This PR would be very very helpful for CAPI. Currently I have a lot of excludes for omitzero cases which is a bit error prone :) Thx for working on this! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add the field with only omitzero tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added, but whats the expectation, Currently linter suggests to add omitempty tag, Should that be honored or should we make changes to avoid that suggestion when omitzero present on optional tags?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upstream guidance is still that omitempty
should be everywhere, but it's useful to have a case where it is omitzero
only, as I would expect that in the case where omitempty
is being ignored, this change should still work
I wouldn't worry about the requiredfields linter right now, that needs a bit of an overhaul |
4a4e30f
to
8191661
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think we are going to need to expand the config to have similar omitempty
style behaviour, but with omitzero
on structs only for now
I'd also like to see more test cases especially with the different configurations
E.g. if the omitzero
isn't present on a struct, do we still recommend it to be a pointer? Or do we say now, no, this should be omtizero (I think the latter is preferable so I'd expect to see some test cases updated to reflect that, right?)
// Since we absolutely have to add the omitempty tag, we can report it as a suggestion. | ||
reportShouldAddOmitEmpty(pass, field, config.OptionalFieldsOmitEmptyPolicySuggestFix, fieldName, "field %s is optional and does not allow the zero value. It must have the omitempty tag.", jsonTags) | ||
if isStruct && hasOmitZero { | ||
// The struct field need not have omitempty tag if it does not have a valid zero value and has omitzero tag. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are going to need similar omitzero
behaviour/configuration as to what we have for omitempty
. The logic below in the else clause is important for when the object is a struct, but does not have omitzero
, we would need to suggest it.
At the moment, I would only recommend the omitzero
checks/recommendations to look at structs
@@ -300,7 +314,7 @@ func getStructZeroValue(pass *analysis.Pass, structType *ast.StructType) string | |||
for _, field := range structType.Fields.List { | |||
fieldTagInfo := jsonTagInfo.FieldTags(field) | |||
|
|||
if fieldTagInfo.OmitEmpty { | |||
if fieldTagInfo.OmitEmpty || fieldTagInfo.OmitZero { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can only rely on omitzero
when the field isn't a pointer, can we check that here?
// structWithOnlyOmitZeroTag is a struct field with a minimum number of properties and has only omitzero tag. | ||
// +kubebuilder:validation:MinProperties=1 | ||
// +optional | ||
StructWithOnlyOmitZeroTag B `json:"structWithOnlyOmitZeroTag,omitzero"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, if we aren't using the ignore policy on omitempty
, we should add omitempty
as well as omitzero
to be consistent with other types
Yep sure, I will update it |
Hey, I was implementing this and I have a functional question? Case 1: Pointer Policy: Whenrequired Result: Struct should be made Pointer. Case 2: Pointer Policy: Whenrequired Result: Struct should be tagged with omitzero (no need to be a pointer) Is my understanding correct |
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Yes, that would work, though I think in this case I would force the |
So I think in this case I'd probably be doing something like kube-api-linter/pkg/analysis/optionalfields/analyzer.go Lines 186 to 189 in 029010b
Does that make sense? Does it then override any point having the ability to ignore the omitzero? (This is a really good question btw) |
Got the points thanks, Then I think it would be better we document these behavior, My only concern is user should not get confused why still its recommending the tags though the policy is ignore. |
I will get back for this soon. |
Add support considerin
omitzero
json tag in optionalfield linter.TODO: